Google Cloud：サービスアカウントの概要をわかりやすくまとめた

初めに

個人のユーザーではなく、「アプリケーションなどの人以外のシステムが使うIAMユーザー」という認識がとっつきやすいかと思います。
まずはその意味がわかりやすいように、Google CloudのIAMアカウントの種類について簡単にまとめます。
※以降、サービスアカウントをSAと省略する場合もあります。

【IAMユーザーの種類】

このIAMというのは権限を管理するための仕組みであり、どのスコープでどの権限を割り当てるのか、といった考え方が基本になります。
Cloud IdentityやGoogle Workspaceに紐づく組織（Google Cloudを使用する時にドメインを紐付ける）自体に権限を割り当てる事も可能ですし、さらにその中（組織の中）に存在するフォルダや個々のプロジェクト単位でユーザーやグループ、そして今回解説するサービスアカウントにロールをアタッチしてポリシーを割り当てる事が可能です。

もしポリシーやロールとの関係がピンとこない場合、基礎知識は過去の記事でも簡単に解説しているので、ちらっと拝見頂ければ幸いです。

Google Cloud：IAMのイメージについてざっくりまとめてみた
Google Cloud：IdPとアカウント周りについてまとめた
# AKIBA.SaaS「Google Cloud：組織作成の基礎」というテーマで登壇しました

組織自体に権限を割り当てて管理するのであれば大きな範囲でポリシーを定義する必要があり、大体は部門ごとに権限を管理できるようにフォルダにポリシーをアタッチしていきます。
さらに別の仕組みとなる組織ポリシーを併用するとその組織自体で実行できる操作を制限することができます。（ロールを持っていても）
少し話前置きが長くなってしまいましたが、今回はその中のIAMアカウントであるサービスアカウントについて解説します。

サービスアカウントとは

冒頭にも書きましたが、アプリケーションやCompute Engine（GCE）が使用するアカウントであり、そのアプリがGoogle Cloudのリソースを使用する時の認証情報としての機能を持ちます。

サービスアカウントの動き

サービスアカウントも他のアカウント同様に、アカウント固有のメールアドレスで識別されます。
そして、アプリにサービスアカウントをアタッチすることで、そのサービスアカウントに許可されたGoogle Cloudリソースにアクセスする事ができます。

【使用例】
①サービスアカウントをGCEインスタンスにアタッチする
→これでそのインスタンスで実行されているアプリケーションがサービスアカウントとして認証されるように設定する事ができます。

②サービスアカウントにロールを付与してポリシー作成する
→これでアプリケーションがGoogle Cloudリソースにアクセスできるように構成する事ができます。

【補足】
・実際には、SAを作成する時に付与するロールを決定することも出来ます。
・今回の説明のようにSAを作成してから、諸々の設定を行うことが出来ます。
・基本ロール、事前定義ロール、カスタムロール、使用しているロール、から選択可能です。
・3番目はSAにロールを割り当て、ポリシーを作成するという意味です。

サービスアカウントの種類

サービスアカウントは全部で3つ存在し、ユーザーが管理するサービスアカウントはその中でも2つあります。
下記に役割をまとめます。（サービスアカウントをSAと省略します）

【補足】
・ユーザー管理のSAは1つのプロジェクトごとに最大100個作成可能（足りない場合には、割り当て増加リクエストも可能）
・Google管理のSAのサービスがリソースにアクセスできるようにというのは例えば公式説明に下記のような記載があります。

Cloud Run でコンテナを実行する場合、このサービスはコンテナをトリガーする Pub/Sub トピックにアクセスする必要があります。

この理解として、そもそもそのリソースを使用する時に必ず行わなければならない操作を自動的にやってくれるためのSAと言う認識で良いと思います。
そしてこのGoogle管理のSAはプロジェクト内に作成されないため、サービスアカウントの表示では確認する事が出来ません。

通常ユーザーとの違い

通常ユーザーとは異なる点について下記にまとめます。

分かりにくい箇所を少し補足です。
Google CloudはGoogleのサービスの中の一つに過ぎないため、サービスアカウントはGoogle Cloud固有のリソースとなります。
逆にCloud IdentityやGoogle Workspace内のユーザー（通常ユーザー）はGoogle Cloudのみで扱うリソースではないため、その他Googleサービスのユーザーとして使用できるのです。

ユーザー アカウントとは異なり、サービス アカウントは Google Workspace ドメインに属していません。

こちらもとても重要な認識しておくべき事項であり、ドキュメントやイベントなどのGoogle WorkspaceのリソースをGoogle Workspaceドメイン全体で共有したとしても、SAには共有されません。

サービスアカウントの権限借用

こちらも大事な機能の一つなので触れておきます。

権限借用とはつまり、1つのサービスアカウントに付与された権限を、他のサービスアカウントやユーザーに短期的に貸与することが出来る機能です。
この権限借用を利用してAPIにアクセスした場合には、借用したサービスアカウントのIDとそのユーザー人身のIDの2つがログとして記録されます。

ただ注意しなければならないのが、公式のベストプラクティスでも記載がありますが、権限借用を利用したなりすましも可能なようなので、この仕組みを使用する際はしっかりと権限の棚卸しや管理がとても重要になります。

まとめ

今回はGoogle Cloudにおけるサービスアカウントの役割について、ざっくりと解説しました。
実際にコンソール画面で作成しなければイメージがしにくいかも知れませんが、前知識としてこの記事が役に立てば幸いです。

ただ、Google Cloudにおける説明のため、他クラウド（AWSやAzureなど）ではポリシーの仕組みが異なる場合が多いので、権限周りの理解はクラウドごとに認識する必要があります。
ただ、サービスアカウント自体の役割はほぼ同じだと思っていいかと思います。逆に、サービスアカウントが出来る動作はやはりそのクラウド独自のものがあるので逐次、理解する必要があるかと思います。

最後に

前職が元パーソナルトレーナーであったため、ダイエット情報や筋トレ情報を積極的に配信したいと思っています！！IT＝脳＝運動＝体調管理⇒全ては繋がっています。

【筋肉がつかない理由③】

端的にいうと、刺激が軽すぎることが多いです。
分かりやすいように例をあげます。

【ベンチプレスを最大重量で100kgあげる男性A】

・ベンチプレス30kg×50回（低重量） を３セット
・ベンチプレス80kg×10回（高重量） を３セット

これを続けた場合、どちらが筋肉の発達が早いでしょうか？？
単純に答えると、発達の速さであればベンチプレス80kg×10回 を３セットだと思います。
基本的に筋トレでの発達は、身体の適応、いわゆるかなり小さい進化だと思っています。

人間が進化するには、それ相応の期間とストレスが必要ですよね。（何千何万年...etc）
進化は言い過ぎなのは重々承知しておりますが、要はそれだけの普段では味わえない負荷が必要なわけです。

[どちらが筋肉の発達が早いでしょうか??]とお聞きしたのは、現代の筋トレ学ではベンチプレス30kg×50回 を３セットの低重量でも筋肉は発達するためです。

ただ、その筋肉の発達の速度、そしてどの筋肉のタイプ（a,x,i）に変貌するかが異なってくる模様です。
しかし、人の遺伝によりそれも異なります。

ということで、最終的な答えとしては、「基本は高重量でトレーニングし、前回の記事に記載した、非線形のトレーニング」を取り入れるのがおすすめです！！
（最後は経験則です笑）